A pass code represents a string of symbols or characters for providing controlled access to a resource. A pass code is known to an individual or group of individuals authorised to access the resource. A copy of the pass code is stored in a security system that protects the resource. When an individual desires to use the resource, he or she enters the pass code into the security system, which checks that the entered pass code matches the stored pass code. Assuming that there is a match, the security system grants the user access to the resource.
FIGS. 1A, 1B, 1C, and 1D represent a variety of situations in which pass codes are used. In FIG. 1A, a user 101 enters a pass code into a terminal 110. Typically terminal 110 is provided with a keypad for this purpose, with the pass code comprising a short string of digits. Such terminals are frequently used to control access to buildings, car parks, and so on. Note that in many cases there is a single pass code that is shared by all users. This pass code is stored in the terminal, and the terminal compares the input from user 101 with the stored pass code in order to validate the user.
FIG. 1B illustrates a variation on FIG. 1A, where the user 101 has a card 102 (and will therefore be referred to as card holder 101B). Card 102 may comprise a smart card with an embedded chip typically incorporating a processor and non-volatile storage. This non-volatile storage is used to hold a pass code in the form of a personal identification number (PIN) for card holder 101B.
In order to use terminal 110, card holder 101B typically engages card 102 into terminal 110, and then enters the PIN for the card. The terminal 110 forwards the user-entered PIN to the card 102 (possibly in encrypted form), where it is compared to the PIN stored on the card. If there is a match, the card holder 101B is assumed to be properly authorised, and so the transaction is allowed to proceed. Note that the converse procedure could also be employed, where the card 102 forwards its stored PIN to the terminal 110, and where it is the terminal that then performs the authorisation comparison between the stored PIN and the user-entered PIN.
Card 102 may be used in the configuration of FIG. 1B as a form of purse for payment purposes. A terminal 110 can be used to load the purse, by feeding cash into the terminal 110, with the cash then being loaded onto the card. Another (or possibly the same) terminal 110 then allows purchases using card 102, where the terminal deducts money for a purchase from the balance on card 102.
FIG. 1C illustrates a configuration where terminal 110 is indicated as being a client system 110C connected by a network 120 to a server 130C. In one example, client system 110C may comprise a desktop personal computer. Network 120 can be any form of wired and/or wireless communications network, such as the Internet, a local area network (LAN), a wide area network (WAN), a mobile phone network, and so on.
The configuration of FIG. 1C might correspond to providing on-line access to an account held on server 130C, such as for email, home banking, Internet betting, and so on. Typically the account is accessed by user 101 providing a user ID to specify the particular account in question, and a pass code, which controls access to the specified account. The pass code is normally in the form of a password comprising an alphanumeric string. The user enters the password into client 110C. The password is then transferred across network 120 to server 130, where it is compared against a stored password for the account. If a match is obtained, the server 130C allows the client 110C to manipulate the account, e.g. to read emails, transfer funds, etc, depending upon the nature of the account.
FIG. 1D illustrates a configuration where card holder 101D uses card 102 to access terminal 110, which in turn is linked to a server 130D via network 120. The configuration of FIG. 1D may correspond to a cash supply system, in which terminal 110 is an automated teller machine (ATM) connected via a private (secure) link 120 to server 130 that maintains account records for card holder 101D. It may also correspond to a conventional credit card purchase, where card 102 is a credit card, and terminal 110 is typically located in some merchant store. Terminal 110 is then connected over network 120 (which may be in the form of a dial-up link) to server 130D.
In one implementation of FIG. 1D, card 102 contains an identifier of user 101D, but not the pass code (PIN). Thus in use, card 102 is typically inserted into or swiped through terminal 110, which allows the terminal 110 to access the account number from card 102. The card holder 101D is then prompted to enter the PIN into terminal 110. The PIN and the account number are transmitted to server 130 for verification. Server 130 confirms that the PIN entered by card holder 101D matches that stored in the server 130 in respect of the account identified by card 102. This model is generally used for ATM transactions.
In another implementation of FIG. 1D, the user pass code is stored on card 102 itself. In this case, the PIN entered by the user can be verified directly against the PIN stored on the card 102, in analogous fashion to that described above for FIG. 1B. Note that in this embodiment, the PIN need not be transferred to the server 130D, since the PIN authorisation has already been performed within card 102. Nevertheless, terminal 110 may still send the PIN to server 110, for example to provide an additional security layer against fraudulent use of card 102 (e.g. for audit purposes). The terminal 110 might also ask the server 130D to confirm that the account is still active (e.g. card 102 has not been stolen) and that the account has sufficient funds for the intended transaction (although this can be done without the server having to receive the PIN).
One problem with the use of pass codes is that they are vulnerable to interception at the point of user entry. One possible attack is to use a “sniffer” program that tracks all inputs to a terminal or other input device. If a customer enters a PIN into a terminal, this may potentially be picked up by such a sniffer program and reported to an adversary. Desktop computers are especially susceptible to this type of attack, given that they are liable to infection by foreign software, for example a virus or a worm, that may act as the sniffer program.
Another vulnerability for pass codes is that an adversary may simply observe a user entering a pass code into a terminal. Since the pass code is often quite short (typically four digits for a PIN), and is entered for each new transaction, it is not difficult in practice for an adversary to acquire knowledge of a pass code through observation in this manner. This is especially true if the pass code is being entered at a public location, such as a supermarket check-out, where it is very difficult to conceal hand movements for keypad entry. The problem is exacerbated by the growing availability of high quality miniature video cameras, which can be used to video PIN entry in a covert manner. Nevertheless, PINs are being increasingly relied upon for transactions involving credit and debit cards in place of conventional signatures.
One way to avoid a user having to enter a PIN for authorisation purposes is by storing a user pass code on a card 102. The pass code from the card can then be transferred to and verified by a terminal 110 (such as in FIG. 1B), or a server 130D (such as in FIG. 1D). In this model, possession of an appropriate card in effect validates the user, so that there is no further requirement for the user to enter a pass code. This is analogous to the situation with a conventional (physical) key for use in a door lock. Indeed, many hotels now use cards rather than keys to control access to guest rooms. A card may also be provided with some property to link it to the legitimate user. For example, the card may carry a photograph of the user, such as with an identification badge.
Using a stored pass code on a card in this manner does not require user entry of a pass code at authorisation time. Therefore, the risk of the pass code being compromised or intercepted at the point of entry is avoided. On the other hand, if a card is lost or stolen, the card may be used to provide authorisation for an illicit party. Thus with this approach, an adversary no longer needs to acquire both a card and also a separate validating pass code in order to gain access to a protected resource, since the pass code is (in effect) packaged onto the card already.
In summary, known authorisation techniques such as the pass code entry mechanisms described above all suffer from some form of vulnerability to attack by an adversary.